@perbergland That's by design. The new typescript package is deliberately focused on just compiling the code, so you should rely on an editor like VSCode (or npx tsc --noEmit) to report errors for the time being. This is an area where we can easily make improvements in the future, but I didn't want Meteor-reported TypeScript errors to be duplicative with errors reported by other tools, in this first version of the typescript package.

@MastroLindus We're following the precedent set by the ecmascript and babel-compiler packages, where you don't have to install Babel yourself, because it's managed by the Meteor packages. This abstraction has been essential to making major updates (from Babel 5 to 6 to 7) completely behind the scenes. If we let developers use whatever version of Babel they'd installed in node_modules, we would have no ability to update those dependencies safely when updating Meteor's Babel integration. I'm open to being persuaded that TypeScript is somehow different, but that's the current reasoning.

Also, I worry about leading people to think any set of options in tsconfig.json is valid and meaningful within Meteor. For example, there are several compilerOptions related to the output directory where TypeScript generates code, and Meteor's compiler plugin system does not dump generated code into a separate directory, so those tsconfig.json options are meaningless within Meteor. As another example, TypeScript has no concept of the modern/legacy differential bundling that Meteor 1.7 introduced, so it's important that Meteor is able to control the various compilation targets (server, modern browsers, and legacy browsers) that are used. I could write a whole blog post about Meteor's handling of import and export syntax, so the tsconfig.json options related to the module system are equally meaningless within Meteor. I hope I'm painting a picture of why we need the typescript abstraction to be relatively air-tight, and why I feel that pretending to support additional configuration would be a path to confusion. With that said, if there are particular tsconfig.json options that you think would be useful to support, please let us know, and we can decide together whether they make sense!